Master-Master Architecture

Master-Master replication, also known as Peer-to-Peer replication, is a system design pattern where multiple nodes (or instances) are all capable of handling reads and writes. Each node is considered a master, and they synchronize data between each other to stay consistent.

Unlike master-slave, where only one node handles writes, in master-master all nodes can perform write operations.

Characteristics of Master-Master

Characteristic	Description
Write at any node	Any master node can handle client write requests
Bi-directional sync	All nodes replicate data to each other to stay in sync
Conflict resolution	Needed when the same data is modified at multiple nodes simultaneously
High availability	No single point of failure; all nodes are active
Eventual consistency	Ensures all replicas eventually converge to the same state

How it work

1. Client sends write request to any master node.
2. The node updates its local copy and then propagates the change to other master nodes.
3. Other nodes apply the update, resolving any conflicts if needed.
4. All nodes now reflect the same final state (eventually consistent).

Use Cases of Master-Master

Use Case	Reason for Master-Master
Globally distributed databases	Handle local writes without latency from cross-region calls
High availability apps	Prevent downtime if one node fails
Offline-first or mobile sync apps	Allow clients to write offline, sync later with conflict resolution

Technologies Supporting Master-Master

Technology	Description
CouchDB	Built-in multi-master with sync protocols
Cassandra	Peer-to-peer with eventual consistency
MySQL (with Galera)	Provides multi-master synchronous replication
Redis Enterprise	Active-active geo-distributed Redis
Firebase Realtime DB	Supports syncing across clients with conflict resolution

Conflict Resolution

When two masters write to the same key at the same time, a conflict arises.

Solutions:

• Last Write Wins (LWW): Use timestamps to keep the latest update.
• Application-level merge logic: E.g., merging two versions of a document.
• Operational Transformation (OT) or CRDTs: Used in collaborative editing apps like Google Docs.

Example of Master-Master

Scenario

A company runs a shopping app with users in Europe and Asia.

• Data is stored in two MySQL nodes:
  • EU_DB
  • ASIA_DB
• Both are masters with Galera Cluster for synchronous replication.

Flow

1. A user in Europe updates their shipping address → write goes to EU_DB.
2. Galera replicates this update to ASIA_DB.
3. A user in Asia updates their phone number → write goes to ASIA_DB.
4. The change is replicated back to EU_DB.

All changes are synchronized in real-time across both regions.

Diagram

                   +-----------+
                   |  Client 1 |
                   +-----------+
                        |
                   +----------+
                   | Master A |◄─────────────────────────┐
                   +----------+                          │
                        ▲                                │
                        │ bi-directional replication     │
                        ▼                                │
                   +----------+                          │
                   | Master B |──────────────────────────┘
                   +----------+
                        |
                   +-----------+
                   |  Client 2 |
                   +-----------+

Pros and Cons of Master-Master

✅ Pros	❌ Cons
High availability (no single point of failure)	Conflict resolution complexity
Scalable for global apps	Harder to guarantee strict consistency
Writes are locally fast (geo-distributed)	Potential for write-write conflicts
Load can be evenly distributed	More complex deployment and monitoring

Master-Slave vs Master-Master

Feature	Master-Slave	Master-Master
Write node(s)	Only master	Any node (all are writable)
Conflict possibility	No (single writer)	Yes (must be resolved)
Availability	Lower (if master fails)	Higher (no single point of failure)
Performance	Read-heavy workloads	Read/write-heavy & globally distributed
Complexity	Lower	Higher